Computer-implemented systems and methods for implementing transfers over a blockchain network

ABSTRACT

The invention provides improved verification solutions for blockchain-implemented transfers. It is suited for, but not limited to, implementation in an SPV wallet. In accordance with one embodiment, a method, system or resource is provided in which Bob verifies a Merkle proof for a first transaction and, upon successful verification, submits a second transaction to the blockchain. The second transaction has an input that spends an output (UTXO) from the first transaction. Generally, the invention provides an arrangement in which Bob sends Alice a payment transaction template (template Tx 3 ) and requests: the full transaction data for all input transactions (Tx 1 , Tx 2 ) comprising at least one output that Alice wants to spend as inputs to a transfer (Tx 3 ); the Merkle path for all input transactions (Tx 1 , Tx 2 ) linking them to their respective Merkle roots associated with their respective block headers; the completed transfer transaction (Tx 3 ). Alice provides this information plus her signature and optionally a change address. Bob can then perform local SPV checks on the input transactions Tx 1 , Tx 2  using transactions Tx 1  and Tx 2 , their corresponding Merkle paths Path  1 , Path  2 , and Bob&#39;s local list of block headers. Bob broadcasts the transfer transaction (Tx 3 ) to the P2P network.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is the U.S. National Stage of International ApplicationNo. PCT/IB2020/050740 filed Jan. 30, 2020, which claims the benefit ofUnited Kingdom Patent Application No. 1902086.6, filed Feb. 15, 2019,United Kingdom Patent Application No. 1902088.2, filed on Feb. 15, 2019,United Kingdom Patent Application No. 1902090.8, filed on Feb. 15, 2019,United Kingdom Patent Application No. 1902089.0, filed on Feb. 15, 2019,and United Kingdom Patent Application No. 1902092.4, filed on Feb. 15,2019 the contents of which are incorporated herein by reference in theirentireties.

FIELD OF THE INVENTION

This invention relates generally to the communication and transfer ofresources via a network, and more particularly to transfers conductedover blockchain networks, and also digital wallets. The invention issuited, but not limited to, wallets for processing transfers ofcryptocurrencies, tokens and other resources which are implemented on orcommunicated over a blockchain.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 shows an illustration of an “offline SPV wallet” in accordancewith an embodiment of the disclosure.

FIG. 2 shows an illustration of an “on- and off-line SPV wallet” inaccordance with an embodiment of the disclosure.

FIG. 3 shows an illustration of a “PoS SPV wallet” in accordance with anembodiment of the disclosure.

FIG. 4 shows a partial and completed template transaction and theassociated Merkle proof in accordance with an embodiment of thedisclosure.

FIG. 5 shows the flow of data and interaction between Alice and Bob whenconducting a transaction using a split SPV wallet in accordance with anembodiment of the disclosure.

FIG. 6 shows a schematic illustration of an embodiment of the disclosurein use.

FIG. 7 is a schematic diagram illustrates a computing environment inwhich various embodiments can be implemented.

FIG. 8 is a schematic diagram showing three transactions and the Merklepaths which can be used to relate them to blocks (headers).

FIG. 9 illustrates the traditional SPV payment method.

FIG. 10 shows an illustration of a method in accordance with anembodiment of the disclosure.

FIG. 11 shows an example of a binary Merkle tree as known in the priorart.

FIG. 12 shows a Merkle proof-of-existence of a data block D₁ in a treerepresented by a root R, using a Merkle path, in accordance with theprior art.

DETAILED DESCRIPTION

This invention relates generally to the communication and transfer ofresources via a network, and more particularly to transfers conductedover blockchain networks, and also digital wallets. The invention isparticularly suited, but not limited to, wallets for processingtransfers of cryptocurrencies, tokens and other resources which areimplemented on or communicated over a blockchain. The invention providesapparatus and techniques which provide numerous technical advantagesincluding but not limited to, improving the security, versatility,resilience and efficiency of digital wallets and blockchain-basedcommunications.

In this document we use the term ‘blockchain’ to include all forms ofelectronic, computer-based, distributed ledgers. These includeconsensus-based blockchain and transaction-chain technologies,permissioned and un-permissioned ledgers, shared ledgers and variationsthereof. The most widely known application of blockchain technology isthe Bitcoin ledger, although other blockchain implementations have beenproposed and developed. While Bitcoin may be referred to herein for thepurpose of convenience and illustration, it should be noted that theinvention is not limited to use with the Bitcoin blockchain andalternative blockchain implementations and protocols fall within thescope of the present invention. The term “Bitcoin” is used herein toinclude all variations of protocols or implementations which derive fromor implement any variant of the Bitcoin protocol. The term “user” mayrefer herein to a human or a processor-based resource.

A blockchain is a peer-to-peer, electronic ledger which is implementedas a computer-based decentralised, distributed system made up of blockswhich in turn are made up of transactions. Each transaction is a datastructure that encodes the transfer of control of a digital assetbetween participants in the blockchain system, and includes at least oneinput and at least one output. Each block contains a hash of theprevious block to that blocks become chained together to create apermanent, unalterable record of all transactions which have beenwritten to the blockchain since its inception. The header of each blockcontains a field which provides the Merkle root for that block. TheMerkle root is generated by repeatedly hashing together pairs oftransaction IDs from the block until a single hash is arrived at. ThisMerkle root provides an efficient mechanism for verifying that atransaction is part of a block because it allows users to verify aparticular transaction without downloading the whole blockchain.

Transactions contain small programs known as scripts embedded into theirinputs and outputs, which specify how and by whom the outputs of thetransactions can be accessed. On the Bitcoin platform, these scripts arewritten using a stack-based scripting language.

In order for a transaction to be written to the blockchain, it must be“validated”. Network nodes (miners) perform work to ensure that eachtransaction is valid, with invalid transactions rejected from thenetwork. Software clients installed on the nodes perform this validationwork on an unspent transaction (UTXO) by executing its locking andunlocking scripts. If execution of the locking and unlocking scriptsevaluate to TRUE, the transaction is valid and the transaction iswritten to the blockchain. Thus, in order for a transaction to bewritten to the blockchain, it must be i) validated by the first nodethat receives the transaction—if the transaction is validated, the noderelays it to the other nodes in the network; and ii) added to a newblock built by a miner; and iii) mined, i.e. added to the public ledgerof past transactions. (Note: validation as described above should not beconfused with the term “verification” as used herein to mean confirmingor checking whether a particular transaction has been included in ablock on the blockchain).

Once stored in the blockchain as a UTXO, a user can transfer control ofthe associated cryptocurrency to another address associated with aninput in another transaction. This is often done using a digital walletwhich stores the public and private key pairs associated with the user'scryptocurrency. There are various forms of known cryptocurrency wallet,including the SPV wallet (Simplified Payment Verification).

In a SPV-based exchange of cryptocurrency between Alice and Bob, bothparties use the same type of SPV wallet. The SPV wallet stores theuser's private and public keys, unspent transactions and block headers.It also has the ability to connect to the blockchain network. The term“block header” is known in the art, and is used to refer to dataprovided at the top of a block of blockchain transactions. The blockheader uniquely identifies the block so it can be located on theblockchain. It comprises fields of data that provide a unique summary orfingerprint of the entire block's contents. The block header includesthe Merkle Root, which is a hash of all of the transactions in thatblock. A user is then able to search the Merkle tree with that root tocheck (i.e. verify) whether a particular transaction was included in aparticular block on the blockchain, without having to download theentire blockchain.

An advantage of the SPV wallet is that it enables power and storageconstrained devices such as phones and laptops to operate within theBitcoin ecosystem because it only needs to check that a transaction hasbeen verified (hence the name “simplified payment verification”) ratherthan performing a full check of the blockchain as per other forms ofwallet. Since an SPV wallet only downloads block headers withoutincluding any of the transactions, this reduces the storage spacerequired from 159 GB (as of November 2018) to 43 MB, and storagerequirements will only increase at a constant 4.2 MB per year even asBitcoins scales.

Suppose that Alice wishes to send some cryptocurrency or a tokenisedasset/resource to Bob. The communication flow between Alice and Bob,when using conventional SPV wallets, is as follows:

-   -   1. Alice creates a blockchain transaction (TX), specifying Bob's        address in the output and providing signatures for inputs (from        previous unspent transactions to Alice).    -   2. Alice broadcasts the transaction to the blockchain network.    -   3. Bob queries the network to verify that the transaction has        been accepted.

In essence, the blockchain network acts as an intermediary betweenAlice's wallet and Bob's wallet. However, not only is this aresource-intensive process, it also requires network connectivity. Ifthe device that the Alice's wallet is running on is offline for somereason, the transfer cannot be completed. Therefore, there are technicalchallenges including, but not limited to, how to provide methods,systems and devices for implementing a more reliable and efficientmechanism for conducting an electronic transfer from one entity (e.g.computing resource/node/digital wallet) to another.

Thus, it is desirable to provide a solution which solves at least thesetechnical problems. Such an improved solution has now been devised.Thus, in accordance with the present disclosure there is provided asystem and corresponding method as defined in the appended claims. Inaccordance with embodiments of the disclosure there may be provided acomputer and/or blockchain implemented method and corresponding systemand/or resource. The resource may be a computer-implemented resource ordevice(s).

The invention may provide or be arranged to facilitate or enable atransfer of an asset (between a transferor and a transferee) on or overa blockchain network. The transferor (sender of the asset) may bereferred to herein as Alice and the transferee (recipient of the asset)may be referred to as Bob. The asset can be or comprise any type oftransferrable electronic entity eg a portion of cryptocurrency or atoken, or anything else that can be transferred digitally in some wayvia a blockchain transaction. Additionally or alternatively, theinvention may be arranged to facilitate or enable verification of ablockchain transaction. Preferably, this is an SPV verification. Theinvention may provide a blockchain-implemented Simplified PaymentVerification method and corresponding system.

A method in accordance with an embodiment of the disclosure may comprisethe steps:

-   -   verifying a Merkle proof for a first transaction comprising an        unspent output (UTXO₁); and    -   sending a second transaction to a blockchain upon successful        verification of the Merkle proof, wherein the second transaction        comprises an input which spends the unspent output (UTXO₁) of        the first transaction.

These steps may be performed by a computer-implemented resource. Theresource may be substantially as described herein in relation to Bob, orthe sections entitled “PoS SPV Wallet” or “split wallet” provided hereinwith reference to the relevant figures. The resource (and/or thecomputer implemented resource) may comprise a combination of hardwareand software, or may be purely software based.

The resource may be referred to hereafter as Bob, and the computerimplemented resource may be referred to as Alice. “Successfulverification” may mean that the Merkle proof establishes that the firstblockchain transaction is present on the blockchain i.e. has been minedinto a block.

The second transaction may be referred to as a payment transaction forease of reference. It may comprise at least one further input whichspends at least one further unspent output (UTXO₂) of the firsttransaction or an unspent output (UTXO₃) of a third transaction. Inother words, the payment transaction that is sent to the blockchain maycomprise more than one input. These inputs may spend outputs (UTXOs)from one or more other transactions. It should be noted that the phrase“third transaction” as used in the claims should be interpreted asmeaning “one or more further transactions” in that the sense that theremay be more than one “third transaction”—there may be any number ofinputs from any number of transactions into the second transaction.

Embodiment(s) of the disclosure may comprise the step of verifying aMerkle proof for the third transaction. In other words, the inventionmay be arranged to verify a Merkle proof for each transaction that isbeing used to provide an output (UTXO) for input into the paymenttransaction.

The method may further comprise the step of receiving, via an off-chaincommunication, a Merkle path and/or complete transaction data for the atleast one transaction and/or the third transaction. The term “off-chaincommunication” may mean that the communication does not involve i.e. govia the blockchain network and/or the blockchain itself

The method may further comprise the step of storing at least one publickey, at least one private key and/or at least one block header.

The method may further comprise the step of requesting, via an off-chaincommunication, the Merkle path and/or complete transaction data for thefirst transaction or third transaction from a computer-based/implementedresource (Alice). The request may be made using a transaction template.The template may comprise some, but not all, of the information requiredto form a valid blockchain transaction. The computer-based resource mayprovide the requested data by updating or completing the transactiontemplate. The template may also be referred to as an “incomplete(blockchain) transaction”.

The method may further comprise the step of receiving, via an off-chaincommunication and from the computer-based resource: the Merkle pathand/or complete transaction data for the first transaction or thirdtransaction; a signature for spending at least one unspent blockchaintransaction output (UTXO) of the first transaction and/or thirdtransaction.

The second transaction may further comprise a change address forspending a portion of cryptocurrency to a destination.

Embodiment(s) of the disclosure also provide a corresponding system. Anyfeature described in relation to a method of the invention may alsoapply to an embodiment of the system, and vice versa.

There may be provided a computer-implemented system comprising:

-   -   a processor; and    -   memory including executable instructions that, as a result of        execution by the processor, causes the system to perform any        embodiment of the computer-implemented method as claimed or        disclosed herein.

The system may comprise at least one Simplified Payment Verificationwallet.

Embodiment(s) of the disclosure also provide a non-transitorycomputer-readable storage medium having stored thereon executableinstructions that, as a result of being executed by a processor of acomputer system, cause the computer system to at least perform anembodiment of the method as disclosed herein.

These and other aspects of the present invention will be apparent fromand elucidated with reference to, the embodiment described herein.Embodiments of the present disclosure will now be described, by way ofexample only, and with reference to the accompany drawings, in which:

FIG. 1 shows an illustration of an “offline SPV wallet” in accordancewith an embodiment of the disclosure.

FIG. 2 shows an illustration of an “on- and off-line SPV wallet” inaccordance with an embodiment of the disclosure.

FIG. 3 shows an illustration of a “PoS SPV wallet” in accordance with anembodiment of the disclosure.

FIG. 4 shows a partial and completed template transaction and theassociated Merkle proof in accordance with an embodiment of thedisclosure.

FIG. 5 shows the flow of data and interaction between Alice and Bob whenconducting a transaction using a split SPV wallet in accordance with anembodiment of the disclosure.

FIG. 6 shows a schematic illustration of an embodiment of the disclosurein use.

FIG. 7 is a schematic diagram illustrates a computing environment inwhich various embodiments can be implemented.

FIG. 8 is a schematic diagram showing three transactions and the Merklepaths which can be used to relate them to blocks (headers).

FIG. 9 illustrates the traditional SPV payment method.

FIG. 10 shows an illustration of a method in accordance with anembodiment of the disclosure.

FIG. 11 shows an example of a binary Merkle tree as known in the priorart.

FIG. 12 shows a Merkle proof-of-existence of a data block D₁ in a treerepresented by a root R, using a Merkle path, in accordance with theprior art.

PRIOR ART: MERKLE TREES

As the present invention utilises the concept of a Merkle tree toadvantage, we provide an explanation by way of background only.

Merkle Trees are hierarchical data structures that enable secureverification of collections of data. In a Merkle tree, each node in thetree has been given an index pair (i, j) and is represented as N(i, j).The indices i, j are simply numerical labels that are related to aspecific position in the tree. An important feature of the Merkle treeis that the construction of each of its nodes is governed by thefollowing (simplified) equations:

${N\left( {i,j} \right)} = \left\{ {\begin{matrix}{H\left( D_{i} \right)} & {i = j} \\{H\left( {{N\left( {i,k} \right)}\left. {N\left( {{k + 1},f} \right)} \right)} \right.} & {i \neq j}\end{matrix},} \right.$

-   -   where k=(i+j−1)/2 and H is a cryptographic hash function.

A labelled, binary Merkle tree constructed according to these equationsis shown in FIG. 11, from which we can see that the i=j case correspondsto a leaf node, which is simply the hash of the corresponding i^(th)packet of data D_(i). The i≠j case corresponds to an internal or parentnode, which is generated by recursively hashing and concatenating childnodes until one parent (the Merkle root) is found.

For example, the node N(1-4) is constructed from the four data packetD₁, . . . , D₄ as

$\begin{matrix}{{N\left( {1,4} \right)} = {H\left( {{N\left( {1,2} \right)}\left. {N\left( {3,4} \right)} \right)} \right.}} \\{= \left\lbrack {{H\left( {{N\left( {1,1} \right)}\left. {N\left( {2,2} \right)} \right)} \right.}{H\left( {{N\left( {3,3} \right)}\left. {N\left( {4,4} \right)} \right)} \right\rbrack}} \right.} \\{\left. {= \left\lbrack {{H\left( {{H\left( D_{1} \right)}\left. {H\left( D_{2} \right)} \right)} \right.}{H\left( {H\left( D_{3} \right)} \right.}{H\left( D_{4} \right)}} \right)} \right\rbrack.}\end{matrix}$

The tree depth M is defined as the lowest level of nodes in the tree,and the depth m of a node is the level at which the node exists. Forexample, m_(root)=0 and m_(leaf)=M, where M=3 in FIG. 11.

Merkle Proofs

The primary function of a Merkle tree is to verify that some data packetD_(i) is a member of a list or set of N data packets

∈{D₁, . . . , D_(N)}. The mechanism for verification is known as aMerkle proof and consists of obtaining a set of hashes known as theMerkle path for a given data packet D_(i) and Merkle root R. The Merklepath for a data packet is simply the minimum list of hashes required toreconstruct the root R by way of repeated hashing and concatenation,often referred to as the ‘authentication path’. A proof-of-existencecould be performed trivially if all packets D₁, . . . , D_(N) are knownto the prover. This does however require a much larger storage overheadthan the Merkle path, as well as requiring that the entire data set isavailable to the prover. The comparison between using a Merkle path andusing the entire list is shown in the table below, where we have used abinary Merkle tree and assumed that the number of data blocks N isexactly equal to an integer power 2. If this were not the case, thenumber of hashes required for the Merkle proof would differ by ±1 ineach instance.

TABLE The relationship between the number of leaf nodes in a Merkle treeand the number of hashes required for a Merkle proof Merkle tree No.data packets 8 32 64 256 N = 2^(M) No. hashes required 3 5 7 9 M = log₂N for proof-of-existence

In this simplified scenario—where the number of data packets is equal tothe number of leaf nodes—we find that the number of hash values requiredto compute a Merkle proof scales logarithmically. It is clearly far moreefficient and practical to compute a Merkle proof involving log_(K) Nhashes than to store N data hashes and compute the trivial proof

Method

If, given a Merkle root R, we wish to prove that the data block D₁belongs to the set

∈{D₁, . . . , D_(N)} represented by R we can perform a Merkle proof asfollows

-   -   i. Obtain the Merkle root from a trusted source.    -   ii. Obtain the Merkle path h from a source. In this case, Γ is        the set of hashes:

Γ={N(2,2),N(3,4),N(5,8)}.

-   -   iii. Compute a Merkle proof using D₁ and Γ as follows:        -   a. Hash the data block to obtain:

N(1,1)=H(D ₁).

-   -   -   b. Concatenate with N(2,2) and hash to obtain:

N(1,2)=H(N1,1)∥N(2,2)).

-   -   -   c. Concatenate with N(3,4) and hash to obtain:

N(1,4)=H(N(1,2)∥N(3,4)).

-   -   -   d. Concatenate with N(5,8) and hash to obtain the root:

N(1,8)=H(N(1,4)∥N(5,8)),

R′=N(1,8).

-   -   -   e. Compare the calculated root R′ with the root R obtained            in (i):            -   I. If R′=R, the existence of D₁ in the tree and                therefore the data set                is confirmed.            -   II. If R′≠R, the proof has failed and D₁ is not                confirmed to be a member of                .

This is an efficient mechanism for providing a proof-of-existence forsome data as part of the data set represented by a Merkle tree and itsroot. For example, if the data D₁ corresponded to a blockchaintransaction and the root R is publicly available as part of a blockheader then we can quickly prove that the transaction was included inthat block.

The process of authenticating the existence of D₁ as part of our exampleMerkle tree is shown in FIG. 12 which shows a Merkle proof-of-existenceof data block D₁ in the tree represented by a root R using a Merklepath. This demonstrates that performing the Merkle proof for a givenblock D₁ and root R is effectively traversing the Merkle tree ‘upwards’by using only the minimum number of hash values necessary.

The present invention uses these techniques to provide a more efficientand secure verification solution, which we now turn our attention todiscussing.

Simplified Payment Verification (SPV)

As the present invention provides improved SPV solutions, we now providean overview of known SPV verification techniques for ease of reference.

In what follows, we consider Alice (a customer) and Bob (a merchant) whowish to transact at the point-of-sale of some goods. We examine how thisinteraction takes place using simplified payment verification (SPV)using the traditional method, as outlined in the Nakamoto whitepaper(“Bitcoin: A Peer-to-Peer Electronic Cash System”, Satoshi Nakamoto,[2008] www.bicoin.org/bitcoin.pdf). The same interaction is describedlater in respect of an illustrative embodiment of the present invention,in the section entitled “Overview of the Invention”. In both cases, weconsider the role of three blockchain transactions (Txs). Twotransactions have spendable outputs (UTXOs) owned by Alice:

-   -   Tx1—a transaction with a spendable output (vout-1)    -   Tx2—a transaction with a spendable output (vout-0)

These transactions Tx1, Tx2 will be referred to herein as inputtransactions as a concise way of saying that they are transactionscomprising outputs that are being spent by the inputs of some subsequenttransaction e.g. a Tx3.

The third blockchain transaction is the payment transaction:

-   -   Tx3—a transaction using vout-0 and vout-1 as its two inputs and        one output paying to Bob. There are only two inputs and one        output for simpler demonstration of the invention.

These three transactions, and the Merkle paths which can be used torelate them to blocks (headers), are shown schematically in FIG. 8.

The basic concept of SPV has existed since the Nakamoto whitepaper andwas implemented in the original Bitcoin client (v 0.1, 2009). Inessence, SPV makes use of two properties of the Bitcoin blockchain:

-   -   1. Merkle proofs that can be used easily to verify that a given        transaction is included in a Merkle tree and represented by a        Merkle root; and    -   2. Block headers that represent blocks of transactions by        including the Merkle root of a Merkle tree of transactions.

By combining these two properties a lightweight Bitcoin client need onlymaintain a copy of the block headers for the entire blockchain—ratherthan blocks in full—to verify that a transaction has been processed bythe network. To verify that a given transaction has been processed andincluded in a block, an SPV client requires only:

-   -   a full list of up-to-date block headers;    -   the Merkle path for the transaction in question.

It follows from property 1 that the SPV user can verify that the giventransaction is part of a Merkle tree—represented by a Merkle root—simplyby performing a Merkle path authentication proof as explained in thesection above. It then follows from property 2 that the transaction isalso part of a block in the blockchain if the SPV client has a validblock header that includes this Merkle root. Performing this type ofpayment verification in bitcoin will be referred to herein as performingan ‘SPV check’.

This SPV mechanism as specified by Nakamoto informs the existing methodof SPV client implementation, including at the point-of-sale.Importantly, the state-of-the-art in SPV implementation is based on theparadigm whereby a user verifies that a payment has been received byconfirming (to a suitable depth on the blockchain e.g. 6) that it hasbeen included in a block. In effect, this is a post-broadcast check on atransaction to verify that it has been mined.

In contrast, the present invention requires that the necessary SPV checkbe performed on a transaction's inputs prior to its broadcast. Thisshift in emphasis greatly reduces the burden and traffic on the networkin dealing with invalid transactions.

A second important paradigm in the existing SPV system is that an SPVclient must query full nodes on the network to obtain the Merkle pathrequired for the SPV check. This can be seen in the Bitcoin developerguide (bitcoin.org/en/developer-guide) which states that “the SPV clientknows the Merkle root and associated transaction information, andrequests the respective Merkle branch from a full node”.

Embodiments of the present invention provide mechanisms and methodsinvolving SPV checks that remove this burden on the network, bystipulating that lightweight bitcoin client users keep, maintain or atleast have access to their own copies of Merkle paths pertinent to theunspent transaction outputs owned by them.

The traditional method for implementing SPV (at the point oftransaction) is as follows, and with reference to FIG. 9:

[1] MESSAGE: Bob to Alice

-   -   Bob (merchant) sends Alice (customer) his public key address.        His message may also include the amount that is to be paid, in        addition to any other spending conditions provided as the hash        of Bob's chosen redeem script.    -   Alice also communicates the transaction ID TxID3 of the payment        transaction Tx3 to Bob (not shown).

[2] The P2P network mediates the exchange between Alice and Bob:

-   -   [2.i] MESSAGE: Alice to P2P network        -   Alice broadcasts Tx3 to the network.    -   [2.ii] MESSAGE: Bob to P2P network        -   Bob queries the network to check whether Tx3 is accepted for            mining into the blockchain.        -   Bob sends continuous queries [2.ii] until he is satisfied            the payment is deemed valid by the network. Note that he may            begin querying before [2.i] has occurred.        -   If Bob is satisfied, he may treat the transaction as            complete without either party waiting for the next block to            be mined.

[3] SPV CHECK (MESSAGE): Bob to P2P network

-   -   Bob waits for the next block to be mined and downloads new block        headers as they are broadcast on the network.    -   Bob sends an ‘SPV check’ request to the network. This is a        request for the Merkle path corresponding to Tx3 that links it        to the Merkle root in a recently-mined block.    -   If the network can provide Bob with the Merkle path, he can        compute the Merkle proof himself using his SPV wallet and check        the payment Tx3 has been processed.

This communication flow is illustrated in FIG. 9. It should be notedthat [2.i], [2.ii] and [3] are mediated by the P2P network and thuscontribute to traffic on the network. It should also be noted that inthe existing SPV paradigm, the necessary SPV check [3] is performed:

-   -   After the payment (Tx3) is submitted;    -   On the payment (Tx3) itself;    -   With the help of other network peers who provide Merkle paths.

We now contrast this known approach with that of the present invention.

Overview of the Invention

The present invention provides improved security solutions forverification on a blockchain network (which we will hereafter refer toas the “Bitcoin” network for convenience) using a low bandwidth SPVsystem. In accordance with an embodiment of the invention, the sender ofthe resource (e.g. customer) does not need to be online for thetransaction to be created and/or accepted by the receiver (e.g. amerchant). Only the receiver needs to be online. For the sake ofconvenience and ease of reference, the term “customer” or “Alice” willbe used instead of “sender”, and “merchant” or “Bob” will be usedinstead of “receiver”.

The present invention employs a novel communication flow between theparties relative to conventional SPV transactions, as it only requiresthe merchant's wallet to be connected to the network. This is achievedby the merchant's wallet creating a template (which may be referred toas an “incomplete transaction”) with information that the customer needsto provide e.g. a change address, signature, etc. Once the merchantreceives this requested information from the customer, he broadcasts thetransaction to the network.

Thus, the invention gives rise to a fundamental change of thecommunication and exchange process between the transacting parties andthe network during a simple payment verification on the Bitcoin networkfrom:

-   -   Merchant→Customer→Network→Merchant to:    -   Merchant→Customer→Merchant→Network

Alice and Bob may securely exchange messages using a secret sharingprotocol such as, for example, that described in WO 2017145016.

This change in process gives rise to the technical problem of needing anovel design for both the customer wallet and also for the merchantwallet. Therefore, embodiments of the invention provide at least thefollowing:

-   -   1. a novel customer wallet for Alice (which we will refer to as        the “offline wallet”): this stores Alice's public keys, private        keys, transactions containing spendable outputs, all block        headers and, importantly, the Merkle paths of the stored        transactions (which removes the requirement for Alice to be        connected to the network)    -   2. a novel merchant wallet for Bob (which we will refer to as        the “Point of Sale (PoS) wallet”:        -   this stores Bob's public keys and all block headers.

A more detailed description of these components is now provided.

An illustrative method for implementing SPV (at the point oftransaction) in accordance with an embodiment of the invention isprovided as follows, with reference to FIG. 10:

[1] MESSAGE: Bob to Alice

-   -   Bob sends Alice a payment transaction template (template Tx3)        and requests the following information from Alice:        -   The full transaction data for all input transactions (Tx1            and Tx2) comprising at least one output that Alice wants to            spend as inputs to the payment (Tx3);        -   The Merkle path for all input transactions (Tx1 and Tx2)            linking them to their respective Merkle roots associated            with their respective block headers;        -   The completed (i.e. filled-in template) payment transaction            (Tx3).    -   Note that Bob is requesting information from Alice, rather than        sending his address.

[2] MESSAGE: Alice to Bob

-   -   Alice sends the requested information to Bob:        -   The full transaction data for all input transactions (Tx1            and Tx2) comprising at least one output that Alice wants to            spend as input(s) to the payment (Tx3);        -   The Merkle path for all input transactions (Tx1 and Tx2)            linking them to their respective block headers;        -   The completed (i.e. filled-in template) payment transaction            (Tx3). In addition to filling in the template, Alice also            provides her signature.

[3] SPV CHECK (LOCAL): Bob

-   -   Bob performs SPV checks on the input transactions Tx1 and Tx2        using:        -   The transactions Tx1 and Tx2;        -   The corresponding Merkle paths Path 1 and Path 2;        -   Bob's local list of block headers.    -   These checks are performed locally by Bob and do not go through        the P2P network;    -   In a preferred embodiment, at this stage that Bob also performs        appropriate checks on the payment Tx3 he has received from Alice        to ensure that:        -   The payment Tx3 is as Bob expected;        -   Alice's signature(s) are valid for this transaction.        -   [4] MESSAGE: Bob to P2P network    -   Bob broadcasts the payment transaction (Tx3) to the P2P network.        In the existing paradigm, Alice would submit the transaction to        the network.    -   This is done only if the SPV check [3] on all inputs to Tx3 are        affirmative.

[5] SPV CHECK (MESSAGE): Bob to P2P network

-   -   This step is identical to the step [3] in the existing paradigm        of SPV methods (see earlier).

This communication flow is illustrated in FIG. 10. It should be notedthat only [4] and [5] are mediated by the P2P network. Step [5] isnothing more than a repetition of the existing SPV technique and is nota necessary feature of our proposed method; it is included here forcompleteness and for distinction between the existing paradigm and thepresent invention.

Note that, in accordance with embodiments of the present invention, thenecessary SPV check [3] is performed:

-   -   Before the payment transaction (Tx3) is submitted;    -   On the input transactions (Tx1 and Tx2) to the payment        transaction (Tx3);    -   Without the help of network peers to provide Merkle paths        (provided by Alice).

Features of embodiments of the invention include, but are not limitedto:

-   -   Alice does not need to be online or submit any information to        the network herself. This is more reliable for Alice. It also        allows her to use a device, such as smart card, that does not        have the capability of connecting to the network.    -   The inclusion of the Merkle path allows Bob to quickly reject        any invalid inputs from Alice. This alleviates excess network        traffic by refusing to submit ‘spam’ transactions with invalid        Merkle paths.    -   Bob may have a particularly fast connection to the network and        so it may be faster for him to validate a transaction.    -   Bob creates the transaction for Alice to sign and therefore has        more control over the content of the transaction, for example he        may choose to pay more in transaction fees which will ensure        that the transaction is accepted by the network.    -   Bob's wallet does not need to contain any private keys. This        increases security as the private keys cannot be accessed or        compromised by an unauthorised third party.    -   The responsibility for submitting the transaction to the network        relies on Bob.    -   Alice's SPV wallet must have a private key and the ability to        sign the transaction. Therefore, it must have enough processing        power to perform elliptic curve point multiplication.

We now consider the various components of the invention in more detail.

Offline SPV Wallet

An embodiment of the offline SPV is shown schematically in FIG. 1 andcomprises the following features:

-   -   1. TXs—Pre-loaded, full transaction data containing Alice's        available unspent transaction outputs. This full transaction        data in combination with a Merkle path constitutes a Merkle        proof that the transaction Alice is spending is valid. Hashing        the full transaction will give the transaction ID (TXID) which        is required as part of the input data for the new transaction        that Alice wishes to complete. Note that providing the TXID        alone would be insufficient as Bob must be able to verify that        the TXID is indeed the hash of the transaction. This is only        possible if she provides Bob with the full transaction data, and        hence she must store it or at least have access to it when        required.    -   2. Private/Public Keys—The wallet must have access to a set of        private keys in order to sign transaction outputs, and also to        public keys to specify change addresses when conducting        transactions.    -   3. Merkle Paths—The (complete) Merkle path of each of the        transactions containing the transaction outputs (UTXOs). This        will be used by the merchant's point of sale wallet to verify        that the TXs are valid. It should be noted that while the Merkle        proof provided by this wallet does not prevent a double spend,        it does act as a fail-fast mechanism against spam attacks thus        providing improved robustness and security of the wallet.    -   4. Minimal Processing—The offline SPV wallet is required to sign        the unspent transactions in order to spend them. This requires        the offline wallet (and device it is installed on) to be able to        implement a cryptographic algorithm such as ECDSA, meaning that        enough processing power is required to be able to perform        elliptic curve point multiplication and compute hash functions.    -   5. Block Headers (optional)—the offline SPV wallet may wish to        include block headers to verify that payments to point of sale        SPV wallets have been processed. This would also require storing        the TXIDs and Merkle paths after interaction with a point of        sale wallet.

In one or more embodiments, the above may be implemented as a walletwith both online and offline states or functionality. This can beadvantageous when the wallet needs to update its set of UTXOs and Merklepaths.

In such an embodiment, Alice's wallet can download data by temporarilyconnecting to the network in the same way that a traditional SPV walletdoes. This is illustrated in FIG. 2, and may be referred to forconvenience as an on- and off-line SPV wallet.

Once connected Alice's wallet can download the full transactions, Merklepaths and block headers. A standard P2PKH transaction as known in theart with 1 input and 2 outputs is 226 bytes, block headers are 80 bytes,and a Merkle path for a transaction in a block containing 100,000transactions is approximately 560 bytes. Combining all three means thatupdating Alice's SPV wallet only needs to download less than 1 MB ofdata per new input. This can be achieved even with a low bandwidthconnection, which is highly advantageous.

A wallet using this implementation is advantageous as it provides thebenefits of being able facilitate offline payments and verificationusing a blockchain, while maintaining the ability to connect to thenetwork as and when needed. The additional online state can be used forupdating the list of block headers, obtaining new TXs and associatedMerkle paths and even sending transactions as and when required.

There are multiple possible use cases for an on- and off-line SPV,including software applications and contactless payment cards.

PoS SPV Wallet

The PoS SPV wallet is designed to achieve the minimum functionalityrequired for Bob to accept a transfer from Alice, who is using anoffline SPV wallet as described above. These requirements are that Bobmust be able to:

-   -   Generate a point of sale transaction template.    -   Compute Merkle proofs associated with block headers.    -   Connect and broadcast to the network, including queries of the        UTXO set.    -   Manage public key addresses for receiving payment    -   Update his list of full TX data containing Alice's UTXOs.

All the above requirements are met by a PoS SPV wallet according to theschematic design shown in FIG. 3 and comprises the following features:

-   -   1. Block headers—the PoS SPV wallet maintains an up-to-date copy        of a list of block header data corresponding to blocks in the        blockchain. When presented with a transaction and its Merkle        path, the PoS SPV wallet can perform a simple Merkle proof by        repeated hashing to the Merkle root.        -   By comparing this root to the one in the relevant block            header, Bob has an efficient fail-fast mechanism for            detecting erroneous or fraudulent payments.    -   2. Network connectivity—the PoS SPV wallet has the ability to        connect to the network. This includes—but is not limited to—the        ability to broadcast a new signed transaction to the blockchain        network and to query for the existence of specific UTXOs in the        current UTXO set.    -   3. Public key storage—the PoS SPV wallet only needs to store the        public key addresses to which Bob wants to receive the asset(s)        or payment. This can be done in several ways such as, for        example, by using a deterministic secret (such as disclosed in        WO 2017/145016) or using a hierarchical deterministic wallet        structure.        -   By only storing public key addresses—rather than the            associated private keys—at the point of sale, security for            ‘card present’ transaction is greatly improved as the Bob's            private keys are not susceptible to compromise, and hence            funds are protected.    -   4. Minimal processing—the PoS SPV wallet is required to perform        only the minimum processing of a Merkle proof based on the        template filled in by the Alice.        -   This greatly reduces the burden of iterating through and            processing full blocks to obtain Merkle paths independently,            which expedites the point of sale/transaction process,            expedites the transfer of the resource across the network,            and improves efficiency for both Bob and Alice.

It should be noted that, in at least one embodiment, the point of saleSPV wallet will maintain a copy of the entire list of block headers toensure that Bob can always perform the SPV check on a Merkle path forany transaction in the history of the blockchain. However, it may be thecase that Bob chooses not to keep the full list of block headers, forinstance those corresponding to blocks containing no transactions withspendable outputs. In this case, it should be appreciated that Bob mayneed to query a third party occasionally to obtain block headers he doesnot already have. In the next section, we detail the Merchant point ofsale template that Bob sends to Alice in accordance with one or moreembodiments and it should be appreciated that, if Bob does not have acomplete list of all block headers, he could incorporate a request forthe block headers associated with her unspent transaction outputs intothis template.

PoS SPV Wallet Template

Turning to FIG. 4, Bob's PoS SPV wallet requests the information forAlice's offline (or off/online) wallet in the following format:

-   -   1. TX/UTX—Full transaction data from Alice's spendable        transaction (as described above).    -   2. Transaction Template—A partially complete blockchain        transaction comprising (at least) Bob's output address and the        amount of cryptocurrency being requested from Alice. In order        for the transaction to be completed, Alice's offline wallet must        provide (at least) the TXID from her unspent transaction output,        a valid signature for each of the spendable TX outputs to be        used, and a change address.    -   3. Merkle Path—When combined with the full, completed        transaction, a Merkle proof can be constructed to verify that        Alice's TX is included in a block and is therefore valid

Note that, in the simplest case, Alice needs to provide Bob with a validpayment transaction Tx3 in exchange for the goods at the P-o-S. Inaccordance with at least one embodiment of the invention, Bob providesthe merchant template to facilitate this but it is also conceivable thata template is not used. For example, if Alice already knows the priceand Bob's address beforehand, she can construct her payment and transmitit directly to Bob. Alice could also provide the required signatures andoutpoint references without explicitly ‘filling-in’ the template itself.

The full transaction (see (1) in FIG. 4) and Merkle proof (see (3) inFIG. 4) can be sent by Alice and processed by Bob. This can be done inparallel with, and independently to, Alice completing Bob's template(see (2) in FIG. 4).

Delayed Transaction Submission:

In some cases, such as for an online retailer, it may be advantageous tosubmit payment transactions in batches at regular intervals. This may bebeneficial for technical reasons such as waiting for improved/optimalnetwork connectivity to be available etc., for accounting purposes orfor reducing the total value of transactions fees incurred.

For the merchant, Bob, this presents no additional challenge but for thecustomer, Alice, this means that the cryptocurrency associated withAlice's change address is not available for her to use until Bobeventually submits the signed transaction to the network.

A solution to the problem would be for Bob to specify the artificialdelay in processing a transaction within the template that he providesto Alice. Alice's offline wallet can interpret this as meaning that thechange generated by the payment to Bob will be unavailable to spendduring the merchant's pre-determined time before submitting theirbatched transactions to the network. It should be noted that there is noadditional risk for Bob in this scenario, as the delivery of thepurchased goods can be cancelled if the merchant finds evidence of adouble-spend before he submits the batch of transactions.

Extension to the PoS SPV Wallet—Split Wallet

As an extension to the PoS SPV wallet described above, it may bedesirable for Bob to utilise several connected wallets, with differentfunctions, which can be treated as single a split-wallet system.

Therefore, certain embodiments of the invention build on the basicconcept of the point of sale (P-o-S) SPV by introducing a more advancedmaster SPV which can coordinate one or many point of sale wallets. Thecombination of a master SPV with one or more P-o-S SPVs will beconsidered a “split wallet” system herein.

The split-wallet system in accordance with embodiments of the inventioncomprises at least one PoS SPV wallet, acting as a payment terminal,coordinated by a master SPV component. The functionality of a master SPVenables the wallet to:

-   -   Store the private keys associated with the public key addresses        of a P-o-S SPV.    -   Compute Merkle proofs associated with block headers.    -   Connect and broadcast to the blockchain network, including        queries of the UTXO set.    -   Communicate with at least one PoS SPV wallet serving as a        payment terminal.

As with all simple payment verification systems, the master walletshould be able to perform all the basic functions of a good SPV, such aschecking the Merkle proof of existence for a given transaction. Thismeans that Bob can check that any transaction he broadcasts from thepoint of sale has been accepted by the network and included in a block.Importantly, however, a master wallet in accordance with an embodimentof the present invention communicates with, and coordinates the paymentsprocessed by, at least one simpler PoS SPV wallet.

It can be advantageous for the master SPV to store the private keys forBob's payment addresses. This allows Bob to have much greater securityover his payment processing when using a split-wallet system. However,storing the Bob's private keys is an optional capability of the masterwallet and its primary function is to aggregate and coordinate paymentsfrom multiple point of sale wallets.

In this implementation of a merchant split-wallet—using only a basicmaster SPV—the merchant-customer interaction is not strictly modified.The PoS SPV wallet must still perform the same checks on Merkle pathsand make the same queries to the network about the UTXO set. Thedifferences in the process include:

-   -   Choice of P-o-S SPV terminal to be used by Alice and Bob.    -   Master SPV should continuously synchronise with the blockchain        in the background.    -   The private keys associated with Bob's payment addresses receive        dedicated management from the master wallet. This adds structure        to the security that was previously introduced by only storing        public key addresses at the point of sale wallet.

It should be noted that a master wallet used as part of a split-walletimplementation would typically reside in a separate location to thepoint of sale SPVs, such as a company back office or head office, forboth security concerns and pragmatism. The merchant-customer interactioncan be visualised as shown in FIG. 5.

As discussed, this implementation using a simple master SPV as part of amerchant split-wallet has utility for the Bob, but still relies on thenetwork for responding to queries of the UTXO set if the split-wallet itto provide a suitable level of double-spend protection.

This may be addressed in accordance with one or more embodiments, inwhich the master SPV is replaced with a more powerful type of masterwallet which also keeps its own copy of the mempool. The split-walletarchitecture equipped with such a master wallet does not need to querythe network to check if a customer's UTXOs are part of the current UTXOset.

A master wallet with its own copy of the mempool functions similarly toa classical non-mining ‘full node’ client but, advantageously, it doesnot need to keep a full copy of the blockchain. Instead, this type ofmaster wallet keeps only the block headers and its own local copy of themempool. The copy of the mempool can either be constructed locally bysynchronising with the network or sourced from a trusted third party orservice.

The implementation of the split-wallet using a master SPV wallet withits own copy of the mempool changes the merchant-customer interactionfrom the perspective of the merchant.

The primary change in the interaction from that described above inrelation to FIG. 5 is manifested in steps 4 and 5:

-   -   In step 4, the merchant only broadcasts the transaction to the        network, rather than adding the additional query of the UTXO set    -   In step 5, the merchant now performs his own check on the        validity of the customer's transaction by checking the mempool        for a conflicting transaction. The merchant can then decide what        action to take based on the state of his synchronised copy of        the mempool.

Illustration of the Invention in Use

Consider a typical merchant-customer interaction where Alice would liketo buy something from Bob. In accordance with an embodiment of theinvention, the process is performed as outlined below, and withreference to FIG. 6:

-   -   1. Bob creates a partially complete blockchain transaction and        requests the following information from Alice. This could be        packaged together as a template for Alice to fill in:        -   a. The TX outputs Alice will spend in order to complete the            purchase        -   b. A (Bitcoin) change address for Alice        -   c. A signature from Alice        -   d. the Merkle path for the TXs (this does not form part of            the transaction)    -   2. Alice completes the template by providing the required        information.    -   3. Bob performs the Merkle proofs to check the validity of the        TXs Alice has provided. If the proofs are not valid Bob knows        that Alice's TXs have never been valid in the blockchain and he        rejects the transaction. Advantageously, this is a fail-fast        mechanism.    -   4. Bob broadcasts the complete transaction to the network and        queries the UTXO set.        -   a. The broadcast allows miners to begin attempts to mine the            transaction into a block.        -   b. The query asks whether the ostensibly valid UTXOs            provided by Alice are still in the UTXO set.            -   This is a mechanism for the prevention of a double-spend                by Alice.    -   5. The network responds to Bob's UTXO query. This allows Bob to        take one of the following courses of action:        -   a. If Alice's UTXOs are still part of the UTXO set, Bob can            accept the payment with minimal risk of a double spend.            -   i. The risk taken by Bob can be minimised by continuing                to poll network nodes with this query for some time                interval r.            -   ii. Bayesian analysis can be leveraged to ensure Bob                queries an honest majority of nodes, within some                confidence interval.        -   b. If Alice's UTXOs are not part of the UTXO set, Bob            rejects Alice's payment.

As mentioned above, embodiments of the invention lend themselves for useand implementation in a variety of forms. These can include paymentcards, for example.

As known in the art, a traditional SPV wallet verifies that atransaction is not a double spend by checking its depth within theblockchain, which it does by querying the network. Once a transactionhas been validated by a miner and is included in a block the transactionhas 1 confirmation. Every additional block added to the blockchainincreases the confirmation by 1 and with each new confirmation the riskof a double spend is decreased. A traditional SPV wallet will display atransaction as “n/unconfirmed” until it has 6 confirmations.

However, the default 6 confirmation rule is not fundamental to Bitcoin.Not all merchants want to wait for 6 blocks (or even 1 block) to begenerated before being satisfied with payment. “0-conf” is the term usedin the art to denote a transaction that has not yet been included in ablock. Once Alice completes her transaction she broadcasts it to thenetwork and Bob should (at the very least) be able to find it in themempool.

The present invention shifts the burden of broadcasting the transactionto the receiver, Bob, rather than the sender, Alice, thus minimising theCPU required and improving the experience for Alice. Bob has a greaterdegree of control over the transaction process as he does not need torely on Alice's connection to the network, but not enough control tocompromise Alice's security. Essentially, Alice (only) has the authorityto accept or reject the transaction by providing a digital signature.

The Merkle path check does not prevent double spending as 0-conf is onlyreached once Bob can see that the transaction being relayed by thenetwork and is in the mempool. Instead, it acts as a fail-fast mechanismallowing Bob to instantly reject attempts to spend non-existent UTXOs.This is useful as it prevents Bob being used as an intermediary for spamattacks, especially since the time taken to broadcast and then query afull node may take more than a few seconds if the connection is poor.

With offline payments enabled, hardware such as pre-paid smart cards canbe integrated into the bitcoin ecosystem. The payment card would requiredata capacity to store private keys as well as the UTXOs, completetransactions and Merkle paths. It would also require some processingpower in order to implement the ECDSA signing algorithm. Table 1 shows alist of some electronic card types available at the time of filing.

TABLE 1 Typical payment card specifications Maximum Cost of Cost of DataProcessing Card Reader/ Capacity Power (USD) Connection Magnetic 140bytes None $0.20-$0.75 $750 Stripe Cards Integrated 1 kB None   $1-$25.0 $500 Circuit Memory Cards Integrated 8 kB 8-bit CPU  $7-$15$500 Circuit (Future Processor expansion up Cards to 23-bit)

Double Spend Protection

Suppose that a customer, Alice, wishes to exchange cryptocurrency forphysical goods in a shop. Traditionally, Alice sends a transaction tothe blockchain network at the point-of-sale (POS) and Bob, the merchant,only allows Alice to leave with the goods when he sees this transactioneither

-   -   (a) gossiped back to him as accepted by the network; or    -   (b) confirmed in a block (or n blocks deep for n-conf).

In scenario (a) Bob knows that Alice's payment transaction to him isvalid and miners will attempt to mine this payment into a block.Although this does not protect Bob from a simple double-spend initiatedby Alice remotely submitting a conflicting transaction, this scenario iscompatible with a conventional block-header based SPV.

In scenario (b) Bob knows that the payment transaction is both valid andhas not been double-spent. However, this requires Bob to run a full-nodeand download the next block(s) in-situ. Also, on the Bitcoin networkthis will take an average of 10 minutes before Alice may leave thepremises with the goods.

It should be noted that in this problem statement, we assume that 0-confsecurity is satisfactory for Bob as the attack we are trying to mitigateis a simple double-spend by Alice. To require one or more blocks is tomitigate a different attack vector—that of a third adversary, Carol,overpowering the entire network.

The following table illustrates how neither scenario (a) nor (b) areindependently acceptable for such a customer-merchant interaction. Thistable shows the transaction features of scenario a) and b):

Factor Scenario (a) Scenario (b) Double-spend protection for Bob NotAcceptable <10 s average transaction time Acceptable Not <10 m averagetransaction time Acceptable Not SPV compatible* (Bob) Acceptable Not SPVcompatible* (Alice) Acceptable Acceptable *This means that there is nofull-node requirement on this party. Only a solution which meets all ofthese criteria is acceptable for both Bob (merchant) and Alice(customer) for most transactions.

Embodiments of the merchant PoS wallet disclosed herein provides thefollowing advantages:

-   -   Double-spend protection for merchant    -   Instant (<<10 s) average transaction time    -   Customer and merchant can both use SPV wallets at the point of        sale.

Factor Scenario (a) Scenario (b) Merchant SPV Double-spend No Yes Yesprotection for Bob <10 s average Yes No Yes transaction time <10 maverage Yes No Yes transaction time SPV compatible* (Bob) Yes No Yes SPVcompatible* (Alice) Yes Yes Yes

It is envisaged that embodiments of the invention are able to provideperformance and results which would be a significant improvement overexisting SPV/cryptocurrency transaction rates, and at least rivalexisting chip-and-pin/contactless terminal payment interactions in termsof instantaneity.

Moreover, the invention also provides allows payments to be consideredcleared and approved with a high degree of certainty withinapproximately one hour (i.e. 6-conf). This is far superior to thecurrent payment clearing times of up to 60-days i.e. VISA and Mastercardclearing times.

Variable Risk

As a merchant, Bob can calibrate the latency for accepting a payment atthe point of sale. By choosing the minimum polling time interval τ healso sets the probabilistic upper bound on the risk of a double-spendacceptable to him. This can allow for greater efficiency and flexibilityin payment processing for merchants.

In addition, Bob can set the mining fee for the transaction whengenerating the template. It does not necessarily matter who pays thisfee, but the value can be used as a parameter for setting the risk ofdouble-spend to a level deemed acceptable by the merchant.

In total the point of sale time delay and the mining fee for thetransaction are two parameters that can be set by the merchant andconsented to by the customer's digital signature that can effectivelycalibrate the efficiency and risk on a case-by-case basis. This maydepend, for example, on the value of the goods to be exchanged,

Turning now to FIG. 7, there is provided an illustrative, simplifiedblock diagram of a computing device 2600 that may be used to practice atleast one embodiment of the present disclosure. In various embodiments,the computing device 2600 may be used to implement any of the systemsillustrated and described above. For example, the computing device 2600may be configured for use as a data server, a web server, a portablecomputing device, a personal computer, or any electronic computingdevice. As shown in FIG. 7, the computing device 2600 may include one ormore processors with one or more levels of cache memory and a memorycontroller (collectively labelled 2602) that can be configured tocommunicate with a storage subsystem 2606 that includes main memory 2608and persistent storage 2610.

The main memory 2608 can include dynamic random-access memory (DRAM)2618 and read-only memory (ROM) 2620 as shown. The storage subsystem2606 and the cache memory 2602 and may be used for storage ofinformation, such as details associated with transactions and blocks asdescribed in the present disclosure. The processor(s) 2602 may beutilized to provide the steps or functionality of any embodiment asdescribed in the present disclosure.

The processor(s) 2602 can also communicate with one or more userinterface input devices 2612, one or more user interface output devices2614, and a network interface subsystem 2616.

A bus subsystem 2604 may provide a mechanism for enabling the variouscomponents and subsystems of computing device 2600 to communicate witheach other as intended. Although the bus subsystem 2604 is shownschematically as a single bus, alternative embodiments of the bussubsystem may utilize multiple busses.

The network interface subsystem 2616 may provide an interface to othercomputing devices and networks. The network interface subsystem 2616 mayserve as an interface for receiving data from, and transmitting data to,other systems from the computing device 2600. For example, the networkinterface subsystem 2616 may enable a data technician to connect thedevice to a network such that the data technician may be able totransmit data to the device and receive data from the device while in aremote location, such as a data centre.

The user interface input devices 2612 may include one or more user inputdevices such as a keyboard; pointing devices such as an integratedmouse, trackball, touchpad, or graphics tablet; a scanner; a barcodescanner; a touch screen incorporated into the display; audio inputdevices such as voice recognition systems, microphones; and other typesof input devices. In general, use of the term “input device” is intendedto include all possible types of devices and mechanisms for inputtinginformation to the computing device 2600.

The one or more user interface output devices 2614 may include a displaysubsystem, a printer, or non-visual displays such as audio outputdevices, etc. The display subsystem may be a cathode ray tube (CRT), aflat-panel device such as a liquid crystal display (LCD), light emittingdiode (LED) display, or a projection or other display device. Ingeneral, use of the term “output device” is intended to include allpossible types of devices and mechanisms for outputting information fromthe computing device 2600. The one or more user interface output devices2614 may be used, for example, to present user interfaces to facilitateuser interaction with applications performing processes described andvariations therein, when such interaction may be appropriate.

The storage subsystem 2606 may provide a computer-readable storagemedium for storing the basic programming and data constructs that mayprovide the functionality of at least one embodiment of the presentdisclosure. The applications (programs, code modules, instructions),when executed by one or more processors, may provide the functionalityof one or more embodiments of the present disclosure, and may be storedin the storage subsystem 2606. These application modules or instructionsmay be executed by the one or more processors 2602. The storagesubsystem 2606 may additionally provide a repository for storing dataused in accordance with the present disclosure. For example, the mainmemory 2608 and cache memory 2602 can provide volatile storage forprogram and data. The persistent storage 2610 can provide persistent(non-volatile) storage for program and data and may include flashmemory, one or more solid state drives, one or more magnetic hard diskdrives, one or more floppy disk drives with associated removable media,one or more optical drives (e.g. CD-ROM or DVD or Blue-Ray) drive withassociated removable media, and other like storage media. Such programand data can include programs for carrying out the steps of one or moreembodiments as described in the present disclosure as well as dataassociated with transactions and blocks as described in the presentdisclosure.

The computing device 2600 may be of various types, including a portablecomputer device, tablet computer, a workstation, or any other devicedescribed below. Additionally, the computing device 2600 may includeanother device that may be connected to the computing device 2600through one or more ports (e.g., USB, a headphone jack, Lightningconnector, etc.). The device that may be connected to the computingdevice 2600 may include a plurality of ports configured to acceptfibre-optic connectors. Accordingly, this device may be configured toconvert optical signals to electrical signals that may be transmittedthrough the port connecting the device to the computing device 2600 forprocessing. Due to the ever-changing nature of computers and networks,the description of the computing device 2600 depicted in FIG. 7 isintended only as a specific example for purposes of illustrating thepreferred embodiment of the device. Many other configurations havingmore or fewer components than the system depicted in FIG. 7 arepossible.

The term “blockchain transaction” may be used to refer to a datastructure which implements the use of a cryptographic key to achievetransfer of control of a digital resource or asset via a blockchainnetwork. As stated above, in order for a transaction to be written tothe blockchain, it must be i) validated by the first node that receivesthe transaction—if the transaction is validated, the node relays it tothe other nodes in the network; and ii) added to a new block built by aminer; and iii) mined, i.e. added to the public ledger of pasttransactions. It will be appreciated that the nature of the workperformed by miners will depend on the type of consensus mechanism usedto maintain the blockchain. While proof of work (PoW) is associated withthe original Bitcoin protocol, it will be appreciated that otherconsensus mechanisms, such as, proof of stake (PoS), delegated proof ofstake (DPoS), proof of capacity (PoC), proof of elapsed time (PoET),proof of authority (PoA) etc. may be used. Different consensusmechanisms vary in how mining is distributed between nodes, with theodds of successfully mining a block depending on e.g. a miner's hashingpower (PoW), an amount of cryptocurrency held by a miner (PoS), anamount of cryptocurrency staked on a delegate miner (DPoS), a miner'sability to store pre-determined solutions to a cryptographic puzzle(PoC), a wait time randomly assigned to a miner (PoET), etc.

Typically, miners are provided with an incentive or reward for mining ablock. The Bitcoin blockchain, for example, rewards miners with newlyissued cryptocurrency (Bitcoin) and fees associated with transactions inthe block (transaction fees). For the Bitcoin blockchain, the amount ofcryptocurrency issued diminishes with time, with the incentiveeventually consisting of transaction fees only. It will be appreciated,therefore, that the handling of transaction fees is a part of theunderlying mechanism for committing data to public blockchains such asthe Bitcoin blockchain.

As mentioned previously, each transaction in a given block encodes thetransfer of control of a digital asset between participants in theblockchain system. The digital asset need not necessarily correspond toa cryptocurrency. For example, the digital asset may pertain to adigital representation of a document, image, physical object, etc. Thepayment of cryptocurrency and/or transaction fees to miners may simplyact as an incentive to maintain the validity of blocks in the blockchainby performing the necessary work. It may be that the cryptocurrencyassociated with the blockchain acts as a security for miners, with theblockchain itself being a ledger for transactions that predominantlyrelate to digital assets other than cryptocurrency. In some cases, itmay be that the transfer of cryptocurrency between participants ishandled by an entity that is different from the entity using theblockchain to maintain a ledger of transactions.

It should be noted that the above-mentioned embodiments illustraterather than limit the invention, and that those skilled in the art willbe capable of designing many alternative embodiments without departingfrom the scope of the invention as defined by the appended claims. Inthe claims, any reference signs placed in parentheses shall not beconstrued as limiting the claims. The word “comprising” and “comprises”,and the like, does not exclude the presence of elements or steps otherthan those listed in any claim or the specification as a whole. In thepresent specification, “comprises” means “includes or consists of” and“comprising” means “including or consisting of”. The singular referenceof an element does not exclude the plural reference of such elements andvice-versa. The invention may be implemented by means of hardwarecomprising several distinct elements, and by means of a suitablyprogrammed computer. In a device claim enumerating several means,several of these means may be embodied by one and the same item ofhardware. The mere fact that certain measures are recited in mutuallydifferent dependent claims does not indicate that a combination of thesemeasures cannot be used to advantage.

1. A computer-implemented method of transferring an asset on a blockchain network, comprising the steps of: receiving and/or requesting, by a resource which is a transferee of the asset and from a further resource which is a transferor of the asset: complete transaction data relating to at least one blockchain transaction, and a Merkle path for the at least one blockchain transaction; and using the Merkle path to verify a Merkle proof for the at least one blockchain transaction.
 2. The method of claim 1, further comprising the step of storing, at or on the resource: at least one public key and/or at least one private key.
 3. The method of claim 1, further comprising the step of storing, receiving and/or requesting, at or on the resource: at least one block header.
 4. The method of claim 3, wherein the at least one block header is received from the further resource, and wherein the further resource comprises a digital wallet.
 5. The method of claim 1, further comprising the step of requesting the Merkle path and complete transaction data by the resource and from the further resource.
 6. The method of claim 1, further comprising the step of sending to the further resource: a public key address; and/or a transfer value.
 7. The method of claim 1, further comprising the step of sending, from the resource to the further resource, a request for transfer data comprising at least one of: data relating to at least one unspent blockchain transaction output (UTXO); a transaction ID (TXID) for a transaction containing the at least one unspent blockchain transaction output (UTXO); a signature for spending at the at least one unspent blockchain transaction output (UTXO); a Merkle path for a transaction containing the at least one unspent blockchain transaction output (UTXO); and/or a public key address.
 8. The method of claim 7, wherein the transfer data is requested by the computer-implemented resource, and/or received from the further resource, using a blockchain transaction template.
 9. The method of claim 6, wherein the transfer data is received from the further resource in the form of a complete blockchain transaction or a partially complete blockchain transaction.
 10. The method of claim 1, further comprising the step of submitting a blockchain transaction to a blockchain network upon successful verification of the Merkle proof for the at least one blockchain transaction.
 11. The method of claim 1, wherein the resource comprises a digital wallet.
 12. A computer-implemented system comprising a resource operative to facilitate a transfer of an asset on a blockchain network, and arranged to: receive and/or request, from a further resource which is a transferor of the asset: complete transaction data relating to at least one blockchain transaction, and a Merkle path for the at least one blockchain transaction; and use the Merkle path to verify a Merkle proof for the at least one transaction.
 13. The computer-implemented system of claim 12, wherein: the blockchain transaction is received by the resource from the further resource in response to a request; the resource is operative to send, to the further resource, a transfer amount and an output address; the first blockchain transaction comprises an output (UTXO) which spends an amount of cryptocurrency to an address specified or determined by the resource.
 14. The computer-implemented system of claim 12, wherein the transfer data is requested by the computer-implemented resource, and/or received from the further resource, using a blockchain transaction template.
 15. A non-transitory computer-readable storage medium having stored thereon executable instructions that, as a result of being executed by a processor of a computer system, cause the computer system to perform the steps of: receiving and/or requesting, by a resource which is a transferee of the asset and from a further resource which is a transferor of the asset: complete transaction data relating to at least one blockchain transaction, and a Merkle path for the at least one blockchain transaction; and using the Merkle path to verify a Merkle proof for the at least one blockchain transaction.
 16. The non-transitory computer-readable storage medium of claim 15, wherein the executable instructions, as a result of being executed by a processor of a computer system, cause the computer system to perform the step of storing, at or on the resource: at least one public key and/or at least one private key.
 17. The non-transitory computer-readable storage medium of claim 15, wherein the executable instructions, as a result of being executed by a processor of a computer system, cause the computer system to perform the step of storing, receiving and/or requesting, at or on the resource: at least one block header.
 18. The non-transitory computer-readable storage medium of claim 15, wherein the executable instructions, as a result of being executed by a processor of a computer system, cause the computer system to perform the step of requesting the Merkle path and complete transaction data by the resource and from the further resource.
 19. The non-transitory computer-readable storage medium of claim 15, wherein the executable instructions, as a result of being executed by a processor of a computer system, cause the computer system to perform the step of sending to the further resource: a public key address; and/or a transfer value.
 20. The non-transitory computer-readable storage medium of claim 15, wherein the executable instructions, as a result of being executed by a processor of a computer system, cause the computer system to perform the step of sending, from the resource to the further resource, a request for transfer data comprising at least one of: data relating to at least one unspent blockchain transaction output (UTXO); a transaction ID (TXID) for a transaction containing the at least one unspent blockchain transaction output (UTXO); a signature for spending at the at least one unspent blockchain transaction output (UTXO); a Merkle path for a transaction containing the at least one unspent blockchain transaction output (UTXO); and/or a public key address. 